R.E.M. | Team Game | Development Breakdown

Game Designer: Chris Kim
Level Designers: Chris Kim, Bethany Yao
Artists: Julia Corsi, Lamesha Coley
Programmer: KZ Zhou

Stakeholders:  Jeff Cavitt, Eli Luna

Description: 
R.E.M. is a 2D puzzle game developed for the Samsung Tab A

------------------------------------------------------------------------------------------------------------------ 

My Responsibilities:

• Organized the Art Style Guide and Visual Development documents during production 
• Communicate with GD and discipline members
• Collaborate with other artists on assets and animations
• Assisted with asset implementation in Unity
• Communicated with Level designers for puzzle aesthetics
• Communicated with other artist for deadlines and divvying of tasks
• Communicated with programmer for certain aesthetic functions (animations, etc.) 
• Received feedback on assets and implemented changes as necesary

CONCEPT PHASE

During our planning/concept phase, I volunteered to act as the team's unofficial art lead, since this was our first team game and working together was new for all of us. For this, it wasn't a monumental task, as we were only a team of five developers. Before even doing any development, our entire team spent a few good days doing brainstorming, trying to keep scope and feasibility in mind.

We didn't want to create another platformer, as that was what the other teams were doing, and we had certain parameters that we needed to follow for production. So we settled on a puzzle, and looked at the puzzles from Bioshock as inspiration.

VISUAL DEVELOPMENT

Having had experience as an art director during my Undergrad Thesis (Tales of the Arukigami), I offered to set up our teams visual development direction during concepting. Steampunk, at its core, was not something that I was super familiar with beyond a basic bastardization of it from literature and other media, so actually having to work within its aesthetics and parameters was an exciting new journey for me as an artist. Since we were such a small team, I wanted everyone to have some sort of input on what went into our visuals, so everyone contributed to the visual development document in one way or another. 

VISUAL DEVELOPMENT DOCUMENT
https://docs.google.com/presentation/d/11cftU-LfA2MQO_MzqZ0l89Mnb-WiI28qt-ECdCnKT9w/edit#slide=id.g4291b37dde_0_17 

PRODUCTION PHASE

During production, we took our puzzle concept and pushed it even further. In order to fit with the pipes theme, we settled on doing a Steampunk-themed game, where the player had to fix broken machinery through the use of their player drones. 

For the level select, I wanted to make it sort of a linear narrative progression that would both make sense to the player but also look clean and refined while conveying as much information in a limited space as possible. For my first iteration, I had the idea that each node (circle) would show a small piece of the machinery that the player was fixing in that level/section of the city. Before completing the puzzles within that node, the image would be dull and grayed out. After completing all puzzles within that node, it would light up, and a trail of light/sparks would travel to the next node. Since our game had a sequential, hinted-at narrative, I designed the background as a condensed sort of map: the brass fence serves as the entrance, and the power generator section, the mid section is the city itself (the levels that corresponded were repairing the water and electricity), and the final section up top is the clock tower, which is the final stage of the city's repair. 

Ultimately, the team's (and myself) had the same concern that it would require too many puzzles that the level designers wouldn't be able to complete with our time constraints, so we settled for the final iteration, which both achieved a similar idea behind the initial concept as well as better convey to the player that they were putting the city back together again.

For the levels themselves, we all wanted to try and integrate the puzzles into the background (and vice-versa) so that we didn't have to deal with having ugly borders around the puzzles. For the puzzle layouts, my main focus was to create an appealing and easy-to-use UI that reflected the Steampunk theme of our game. My other artist, Lamesha, and I did a few brainstorming sessions on how to integrate the puzzle nodes with the background. [Please see her works for her concepts! [Lamesha's Portfolio]]

PUZZLE NODES

Ultimately, we went with the idea of using bolts/screws/rivets to serve as the puzzle nodes, to further fit in with the industrial/steampunk machinery vibe we started to lean into during development. 

The puzzle nodes themselves went through a few stages of iteration, mostly so we could find the most visually pleasing middle ground with them as possible, that looked good but also didn't take up too much space on the screen. 

We first went with the nodes in the 2nd, 3rd, and 4th column, but found that they were too big, and took up too much space or didn't fit nicely within the screen space. Thankfully I designed a variety of options for our level designers to choose from, and I didn't have to design new nodes on the fly. 

BACKGROUNDS

Each background seen in our game represents a different part of the city of Ashburrow. As a team, we decided that we should try and work a narrative into our game in some way, even if it wasn't a direct narrative (due to time and scope, as well as the nature of our game). 

STAGE 2 BACKGROUND:

 For each background we had, the team and I wanted to convey a story through visual narrative. The Stage 1 background is the power generator. Upon completing each puzzle within this stage, the power is restored in Ashburrow and the player can progress

STAGE 2 BACKGROUND:
The Stage 2 background is the boiler. Upon completing each puzzle within this stage, the water system begins to run again.

STAGE 3 BACKGROUND:
This was actually a paintover of the original version (concept remained the same) that Lamesha drafted and cleaned up. Due to stakeholder feedback that it didn't match style consistency, and she was in charge of all of our sprite animations, I asked if it was okay for me to do a paint-over, since I would be able to do it quickly.

THE CHARACTER(s)

Given the nature of our game (Puzzle), there wasn't a lot of room for any legitimate instances of the character, REM, so we settled for using his Drones as the main characters in gameplay. We built this whole little narrative around REM and his drones, which I think helped ground the purpose and intent of our gameplay to a helpful degree - we weren't creating without purpose, and I think it added a smidgen more personality into our final outcome. 

Without further ado, meet REM - the unseen main character of R.E.M. and the role that the player takes on during gameplay. 

I think it was me who pitched the idea of having a "Player character" even if the player never actually saw him, as it put into context why we were controlling our little Drones that repair the machines. When designing REM, I wanted to have a sort of clunky, cobbled together feel about him without actually being made from scraps. After all, he was once a war machine, and I figured those would have come from someone with money.

I referenced Yoko Taro's Nier: Automata frequently when designing REM, as he did an amazing job with getting that industrial machine feel with the Machine Lifeforms that you see in-game. I also wanted to give REM that sort of Victorian-era newspaper boy feel with his hat and goggles, and I personally think it adds a decent amount of charm to his design as well. 

I really loved the clunkiness of the Machine lifeforms, and wanted to capture that sort of shape language in Rem. His huge hands also contributed to the use of the Drones, making them a necessity to fix machinery. I imagine them to be somewhat clumsy, with a sort of Baymax (Big Hero 6) feel about them. He's clumsy but he's doing his best. 

As for the drones, Lamesha handled most, if not all, of the design iterations for them. I simply offered some feedback and suggestions along the way. [VIEW HERE]

ANIMATION

I only assisted with completing one set of the Drone's animations to help Lamesha with her workload, as she was responsible for 98% of all animations seen in our game and had more familiarity with pixel art animations in context of a game than I did. I didn't want to have a hand in everything, as I thought that would be wrong, especially on such a small team. 

The only animations I helped with were the 'Crash' animations, which play whenever the drones collide paths with each other. It was a fun little dip back into my roots (Digital art and animation) and animating in a pixel style was new to me, so it was a fun little experience to have. 

This was also my first time working with sprite sheets, as I had never had a reason to work with them let alone familiarize myself with the concept of what they do. Thankfully, Lamesha was able to provide assistance for me and taught me something. 

PROJECT POST-MORTEM

WHAT WENT WELL:

• Communication between all members of the team went very smoothly and the dynamics were quite favorable
• Staying on task consistently for all members of the team - everyone did their jobs diligently and nobody slacked off
• Artists were very compatible and agreeable, and knew how to play to their strengths and overcome weaknesses
• Understanding of keeping scope manageable was important to EVERYONE
• Level designers did an amazing job at creating puzzles and their solutions - I mean, they really cranked them out
• Programmer did an amazing job with Unity and getting functionality for all aspects of the game up and running

WHAT WENT WRONG:

• Some time management skills for attendance needed some work - or communication when late
• Some members worked outside of core hours
• Too many devs in the dev-room (a lot of us had multiple skill sets that sometimes would overlap)
• Artists didnt have a hand in integration - mostly due to the nature of Unity + Perforce and that the LDs were always in Unity

EVEN BETTER IF: 

• Professors/stakeholders of the course had more teaching moments during development, instead of being as hands-off as they were
• Artists had more chances to integrate assets and understand Unity more cohesively
• More test builds had been done on a more frequent basis
• We paid more attention to the pipelines we had set up for ourselves